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@ t In a multiprotocol environment, a new socket 
structure is provided which moves the decision 
on which protocol to use until the time that the 
connection is actually made between nodes in 
the network. The new socket structure is 
created for every endpoint. All the protocols 
which could potentially be used to send or 
receive data is sent a request to create a pro- 
tocol control block at the time the new socket is 
created. A selection process determines which 
of the protocols could be used by the endpoint 
The new socket then contains information on 
each selected protocol. At the time a connec- 
tion is established, any of the selected protocols 
could be used. The choice of which protocol to 
use can be based on user preferences, which 
protocols are available, the name of the service 
unit 
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BACKGROUND OF THE INVENTION 

This invention relates generally to data communication in a network of computer systems. More particu- 
larly, it relates to a communication endpoint structure which enables application programs resident on systems 
5 to communicate through such a network irrespective of the protocol for which the application was written and 
the protocols available on the network. 

Once upon a time, almost all computer systems were standalone processors to which private, peripheral 
devices such as displays, printers and disk drives were connected, acting independently from any other com- 
puter system. Yet, it became apparent that there were substantial gains to be made if several computer sys- 
10 terns could be cooperatively coupled together. Today, it has become commonplace to couple a multitude of 
computer systems into a distributed environment such as a local area or wide area network. 

However, there are many vendors who have developed their own hardware and software solutions for in- 
tegrating multiple computer systems. In particular, they have developed different ideas of the format and pro- 
tocols that should be followed in transporting data through the networks. Some protocols support expedited 

15 data transmission by bypassing the standard data flow controls; others require all data to go through the con- 
trols. Specialized protocols are used for transport tasks such as establishing and terminating connections be- 
tween computer systems. Examples of well known communication protocols include System Network Archi- 
tecture (SNA), Digital Network Architecture (DECnet), Transmission Control Protocol/Internet: Protocol 
(TCP/IP), Network Basic Input/Output System (NetBIOS), Open Systems Interconnection (OSI) and AppleTalk. 

20 Other protocols are known and widely used. 

Most distributed application programs are written to an application programming interface (API) which as- 
sumes a particular communications protocol. However, the distributed environments which most organizations 
have assembled are quite complex, comprised of confederations of individual networks running different com- 
munication protocols. If the transport protocols assumed by the distributed application's API and the transport 

25 protocols actually implemented in one or more of the networks on which the organization would like to send 
its data are not the same, the use of the application is limited. The problems of such heterogeneity in commu- 
nications protocols is expected to get worse as more organizations begin to communicate with each other 
through their networks to perform order processing, direct billing or other cross organization activities. 

While the distributed applications could be rewritten so that they can run over each transport protocol or 

30 application gateways can be written for each distributed set of distributed applications, the cost of having pro- 
grammers write all the necessary code makes these approaches economically unattractive. A preferred solu- 
tion is presented in copending application, Serial No. 731,564, entitled "Compensation for Mismatched Trans- 
port Protocols in a Data Communications Network", by R.F. Bird etal, filed July 17, 1991 and hereby incorpo- 
rated by reference. The incorporated application teaches a transport connection layer between a first transport 

35 user at one node in the network and a second transport user at a different node in the network. When the 
transport protocol assumed by the application at the first node is not available in the network, the data being 
transferred between the two nodes is automatically altered to be compatible with the available transport pro- 
tocols. Thus, an organization is able to choose application programs solely on the basis of the functions they 
provide, rather than the protocols which they require. 

40 The above referenced application teaches a generalized transport layer. One of the transport structures 
which is presently used in the Berkeley version of the UNIX(TM)environment is called a socket. A socket is an 
object that identifies a communication endpoint in a network. A socket hides the protocol of the network ar- 
chitecture beneath from the application. A socket allows the association of an endpoint, such as an application 
program, with one of the selected protocols. This association occurs when the endpoint is created. An endpoint 

45 creation implies a static association of the socket with the protocol, which will remain invariant. However, in a 
multiprotocol environment, as described in the above referenced application, which facilitates heterogeneous 
connectivity, a transport endpoint may need to be bound to any of several connectivity, a transport endpoint 
may need to be bound to any of several available protocols after the creation of the endpoint. Therefore, if 
sockets are to be used in such an environment, a new socket structure which allows dynamic association of 

so the socket with the protocol must be devised. The present invention teaches such a socket structure. 

Summary of the Invention 

The present invention provides a system and a method for communicating between nodes in a computer 
55 network in which a plurality of protocols are useable by network nodes, the method comprising the steps of 
creating communication endpoint objects defining communication parameters for respective network nodes, 
the objects having information about the plurality of protocols which are useable by said node for inter-node 
communication; and at the time communication is requested between said nodes, establishing a connection 
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between said nodes using a selected one of the plurality of protocols. 

The present invention thereby facilitates late binding of an endpoint to a transport protocol in a distributed 
environment, enabling a more dynamic association between protocol and endpoint. 

Preferably, the invention allows native access to a protocol by an application. It is also preferred that the 

5 invention provides the necessary information for non-native connections to a protocol. 

The invention provides, in a preferred embodiment, a new socket structure which moves the decision on 
which protocol to use to the time that the connection is actually made between nodes in the network. In a mul- 
tiprotocol network, the new socket structure can be created for every endpoint For all of the protocols which 
could potentially be used to send or receive data a request is made to create a protocol control block at the 

10 time the new socket is created. A selection process determines which of the protocols could potentially be used 
by a given endpoint The new socket for the endpoint then contains information on each of the selected pro- 
tocols. At the time a connection is established, any of the selected protocols could be used. Native or non- 
native connections can be made. The choice of which protocol to use or the order of protocol preference can 
be based on user preferences through configuration, the local cache, or information from the named service 

15 unit 

Brief Description of the Drawings 

The invention will now be described in more detail, by way of example, with reference to the accompanying 
20 drawings in which: 

FIG. 1 is a diagram of two single protocol networks coupled together through a multiprotocol transport net- 
work. 

FIG. 2 is a block diagram of the transport interface used according to an embodiment of the present in- 
vention. 

25 FIG. 3 is a diagram of a conventional socket control block. 

FIG. 4 is a diagram of the socket control block according to an embodiment of the present invention. 

FIG. 5 is a flow diagram of the creation of a socket according to an embodiment of the present invention. 

FIG. 6 is a flow diagram of establishing a connection in a multiprotocol transport network environment, 
using a multiprotocol socket according to the invention. 
30 FIG. 7 is a representation of a computer system including system unit, keyboard, mouse and display. 

FIG. 8 is a block diagram of the computer system components depicted in FIG. 7. 

Detailed Description of the Drawings 

35 The following description describes a socket based architecture. However, the invention is not limited to 
sockets and could be applied to similar communication endpoint objects in other operating systems. 

Although the following description contains an adequate disclosure of conventional socket and network 
architecture to allow one skilled in the art to understand the present invention, the reader is referred to The 
Design and Implementation of the 4.3 BSD UNIX Operating System by S. J. Leffer et at, 1989 which is hereby 

40 incorporated by reference, for a more complete understanding of operating system based on the Berkley ver- 
sion of UNIXTM. Such operating systems are well known. 

FIG. 1 shows three single protocol networks 10, 12, 14 which are interconnected through a gateway 59 
built according to the principles of the present invention. With the growth of network distributed environments, 
it is not uncommon to see networks using four or five different protocols, such as TCP/IP, NetBIOS, SNA or 

45 AppleTALK. Since applications which run on one network will not often run with applications on the other, trans- 
port of data throughout the network is hindered. As discussed above, the Multiprotocol Transport Network 
(MPTN) 16 as taught in the above referenced application addresses these problems by defining an interface 
and a compensation mechanism to a set of transport services that provide connections across a plurality of 
transport protocols. By providing a transport boundary between the networks and the applications resident 

so on systems, MPTN provides a common transport interface so that messages from the applications can be 
transported over any protocol in the network. 

As shown in FIG. 1 , hosts 20 and 22 are coupled to the multiprotocol transport network 1 6. While the MPTN 
16 appears as though it is a single logical network having a single protocol, host 20 is coupled to a first network 
10 which communicates via protocol X, e.g., TCP/IP, and host 22 is coupled to a second network 12 which 

55 communicates via protocol Y, e.g., NetBIOS. 

Application program A 24 resident in one of the hosts 20 coupled to the MPTN network 16 wishes to com- 
municate to application B 26 resident in another host 22 also coupled to the network 16. Upon application A's 
call to the socket layer 27, a socket is created by the socket layer 27 defining application A as an endpoint. 
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Sockets contain information about their type, the supporting protocols used in the transport layer 28 and their 
state. A connection request goes through the transport layer 28, the network layer 29 and the network interface 
layer 30 which add the necessary control and data information before the message is sent out on the network 
54. Compensation for the differences between protocol y and X is carried out by the transport layer as taught 
by the above referenced application. 

FIG. 2 depicts the code modules in memory at a computer system which is coupled to the multiprotocol 
transport network in greater detail. The socket programming interface 60 and common transport semantics 
62 correspond to the socket layer and separate the applications 64, 66, 68 from the service drivers 70, 72, 
74. Three types of applications 64, 66, 68 are shown in the application layer. To utilize the socket structure of 
the present invention, NetBIOS applications would be rewritten to the socket API to become the NetBIOS sock- 
et application 66. The standard local IPC socket application 64 and TCP/IP applications 68 are already written 
to a standardized socket programming interface and so would require an minimum of revisions. The common 
transport semantics 62, include the socket control blocks, which will be described in greater detail below. An 
interface between the socket layer and the transport layer is comprised by the local IPC service driver 70, the 
NetBIOS service driver 72 and the INet service driver 74 which correspond to the applications in the application 
layer. The service drivers are used to emulate the common transport semantics for the transport protocol driv- 
ers in the transport layer. In the present invention, they may also contain the compensating means described 
in the above referenced application which converts a message intended for a first protocol by the application 
to a second protocol supported by the network. The transport layer includes the NetBIOS 76 and TCP/IP 78 
protocol drivers which cause the application message to conform to the protocol format There is no corre- 
sponding local IPC module as it describes a local protocol whose messages are not placed on the network. 
The network and network interface layers are not pictured, the latter would include device drivers for the I/O 
hardware which couples the computer system to the network, e.g. a token ring or ethernet driver; the former 
might include drivers written to the well known NDIS interface. 

A socket is the object in the Berkeley version of UNIX(TM) from which messages are sent and received. 
Sockets are created within a communication domain as files are created within a file system. A communication 
domain summarizes the sets of protocols, the naming conventions, the hardware which may be a particular 
network and may use an address which refers to the communication domain. The internet domain specified 
by the address family AFJ NET; the NetBIOS domain is referenced by the address family AF_NETBIOS. Acon- 
nection is a means by which the identity of the sending socket is not required to be sent with each packet of 
data. The identity of each communication endpoint is exchanged prior to any transmission of data and is main- 
tained at the transmitting and receiving nodes, so that the distributed applications at each end can request 
the socket information at any time. 

When an application creates a socket endpoint for a certain protocol and the protocol chosen by the trans- 
port network matches that protocol, native networking has occurred. For example, the INet protocol is used 
to support the INet address family and NetBIOS supports the NetBIOS address family. On the other hand, 
when the transport protocol does not match the socket endpoint of an application it is termed non-native net- 
working. Using the present invention, however, the application is unaware that a different transport protocol 
is being used to connect with other nodes in the network. 

In the present invention, the socket interface is used to connect between replicas of a distributed appli- 
cation or the client and server portions of a client/server application using a variety of transport protocols. The 
application can select the transport protocol or request that the socket layer determine the protocol. With the 
non-native networking feature of the present invention, applications written to communicate with one another 
using one protocol can choose to communicate on another transport protocol which might be optimized for the 
network environment. For example, an application written for TCP/IP could communicate using the NetBIOS 
protocol over the network,giving the distributed application a significant performance gain. 

A conventional socket control block is depicted in FIG. 3, a socket control block 100 contains information 
about the socket, including send and receive data queues, their type, the supporting protocol, their state and 
socket identifier. The socket control block 100 includes a protocol switch table pointer 104 and a protocol con- 
trol block pointer 1 06. The pointers are used to locate the protocol switch table (not pictured) and the protocol 
control block 102 respectively. The protocol switch table contains protocol related information, such as entry 
points to protocol, characteristics of the protocol, certain aspects of its operation which are pertinent to the 
operation of the socket and so forth. The socket layer interacts with a protocol in the transport layer through 
the protocol switch table. The user request routine PR_USRREQ is the interface between a protocol and the 
socket. The protocol control block contains protocol specific information which is used by the protocol and is 
dependent upon the protocol. 

A socket control block according to the present invention is shown in FIG. 4. Here, the socket control block 
110 is shown broken into two sections, the main socket control block which is largely identical to the conven- 
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tional socket control block above and the MPTN extension 112 which contains many of the features necessary 
for the present invention. Both are linked together by a multiprotocol transport network extension 113. Each 
of the protocols which could be potentially used to send or receive data is sent a request to create a protocol 
control block 120, 122 at the time the new socket is created. After a selection procedure, the new socket then 
contains information regarding each selected protocol, the protocol switch table pointer 114, 118, the protocol 
control block pointer 116, 119, and a pointer to a interface address if applicable for the particular protocol (not 
pictured). As above, the protocol switch table pointer refers to a respective protocol switch table which defines 
various entry points for that protocol. Also, the protocol control blocks 120, 122 contain protocol specific in- 
formation. 

At the time of socket creation, no connection is made to any particular protocol to the application endpoint. 
Connection implies an association of the connection-requestor socket of the requesting application to another 
connection-acceptor socket. It can be viewed as a communication wire running between the two sockets that 
are "connected", potentially in two different continents, providing the ability for both of them to send and receive 
messages. There is no difference between a transmitting socket and a receiving socket for the present inven- 
tion. After a connection, each can send or receive data 

The decision on which protocol to use is delayed until the time that the connection is actually made. At 
the time of establishing a connection, any of the network interfaces in a protocol could be used. The order in 
which the pointers which refer to the protocols and network interfaces is based on user preference, information 
from the named service unit or the capability of the protocol the socket extension 1 1 2 which contains the poin- 
ters 114, 116, 118 and 119, also includes state information on the socket and the multiprotocol transport net- 
work. The socket extension 1 1 2 is used by the socket layer to manage the socket and MPTN states. From the 
list of available protocols, the socket layer picks those protocols that support the requested socket domain and 
the type of communication (datagrams, streams, etc), as described in the flow diagram for socket creation de- 
scribed betow. 

A sample socket control block structure is given in the code below: 
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/* socketva.h 

* Kernel structure per socket. 

* Contains send and receive buffer queues, 

* handle on protocol and pointer to protocol 

* K iv ^ e ? ata * error iT »fomation and MPTN extensions. 

* ? « SmK* ot *} h J s structure ( upto the so mptn field ) is 

* to the BSD4.3 socket control block. 
*/ 

struct socket { 

short so,type; 
short sorptions: 
short sojinger: 
short so_state; 
caddr_t sojxrb; 

struct prbtosw far *so_proto; 

/* 

* Variables for connection gueueing. 

* Socket where accepts occur is so_head in all subsidiary sockets 
! i f ^-tead is 0. socket is not related to an accept. 

For head socket sojp queues partially completed connections, 
while so.g is a gueue of connections ready to be accepted 
, !J J connection is aborted and it has so.head set. then 
| J* h J s to pulled out of either so qO or so q. 
He allow connections to queue up based on current queue lenqths 
and Unit on number of queued connections for this socket. 



identical 



/* generic type, see socket. h */ 
V» from socket call, see socket. h V 
/* time to linger while closing */ 
/* internal state flags SS *, below */ 
/* protocol control block */ 
/* protocol handle */ 



*/ 



struct socket far *so_hcad; 
struct socket far *so gO; 
struct socket far *so~q; 
short sojjOlen; 
short so glen; 
short solgliiit; 
short so_tineo: 
u_short so_error; 
short so_pgrp; 
ujona so oobmark; 
Variables for socket buffering. 

struct sockbuf ( 

ujong sbcc; 



/* back pointer to accept socket */ 
/* queue of partial connections */ 
/* queue of mconing connections */ 

/* partials on so_qO */ 

/* number of connections on so q */ 

/* max number queued connections */ 

/* connection timeout */ 

/* error affecting connection */ 

/* pqrp for signals */ 

/* chars to oob mark */ 



ujong 
ujong 
ujong 
ujong 
struct 
struct 
short 
short 



sbjiwat; 
sbnbcnt; 
sb_mbmax; 
sbjowat; 
ubuf far *sb_mb; 
proc far *sb_sel 
sbjimeo; 
sbjlags; 



/* actual chars in buffer */ 

/* max actual char count */ 

/* chars of mbufs used */ 

/* max chars of mbufs to use */ 

/* lov water mark (not used yet) */ 

/* the mbuf chain V 
; /* process selecting read/write */ 
/* timeout (not used yet) */ 
/* flags, see below */ 



} so_rcv. so_snd; 



/* MPTN SOCKET EXTENSION */ 

struct m_esock far * sojiptn; /* socket MFTN extensions V 



ftdefine SB.HAX 
ttdefine SB.LOCR 
tdefine SB_HANT 
ttdefine SB WAIT 
ftdefine SB SKL 
#define SB~C0LL 
): 



< (ujong) (64*1024D) 
0x01 
0x02 
0x04 



0x10 



/* max chars in sockbuf */ 
/* lock on data queue (so rev only) */ 
/* someone is waiting to lock V 
/* someone is waiting for data/space V 
/* buffer is selected */ 
/* collision selecting */ 



55 



/* Socket extensions for MPTN 

\ s sfs^ssj as'siiS' strucln,e vhich contains 

Since n.esock the HPTM extensions to sockets, is contained in one 
* JrtJS r ° St ° f " bUf Space t0 the Jcb* 



6 



EP 0 613 274 A2 



*/ 

/* defines the structure for storing additional pointers. 

* used in n esock. 

* The structure n_addr defines the address fornat.lt is defined in nptndef.h. 

* The structure if info defines the user specified connection characteristics 

* and is defined In nptndef.h. 

* The structure bnlst defines the user configured protocol preference list 

* and is defined in nptndef.h. 



10 



15 



20 



struct n_sopcb ( 

" struct protosw far * so_proto: 
caddrj; so_pcb; 
struct n.addr far * sobnsap; 



); 

struct n.conn.stat ( 
char" type; 

cbar index; 



caddr_t ftnan; 



/* protocol switch ptr */ 
/* pointer to the PCB */ 
/* the network interface 
* the PCB refers to */ 



/* DST BNSAP FOUND.USE PREF LIST.CACHE. 
* GWjfEXT.HOP. GHJNSAP V" 
/* current network... as an index in to the 

* pref. list as the case is. 
*/ 

/* destination nane..for ABM case. Gateway 

* cases , it is dst.bjiam. 

* In the native case or cache case, contains 

* the dest A-addr 
*/ 



that 



25 



struct bnlst far *prf 1st; /* pointer to the pref list */ 



30 



35 



40 



struct n esock ( 

int (» iojipcall ) 0: /* 
struct socket far * so_relay; /* 

struct n_info far 

struct njnfo far 

short so_donain: 

struct n_addr far 

struct n~addr far 

struct nbuf far * 

struct nbuf far * 

struct socket far 



user u pea 11 address V 
relay socket pointer:for gateway only */ 
/* connection chars given at n_create()*/ 
/* conn. char of a connection *7 
/* user specified donain */ 
/* local user nane */ 
/* peer user name */ 
/* connection/ternination data */ 
/* expedited data V 

/* linked list of nonnative scbs.to search 
* for user-names*/ 

/* nptn flags having the following defs*/ 
/* to maintain nptn_connect status */ 
/* nunber of pebs currently in sopebi I */ 
/* peb state:bit position corresponds to 
1 peb array; 0->in-use; else not-in-use*/ 
n_sopcb sopcb IHPTN_MAXPCBI;/* array of n_sopcb structures */ 



* sojnfo; 

* so_cinfo: 

* sojanan; 

* sojianan; 
so_ctaata 
so_expdat 

* so next 



unsigned sojiptn.flag; 
struct n_conn_stat conn_stat; 
short solpcbnun : 
long so_pcbstat; 



struct 



45 



50 



55 



idefine MPTN NONNATIVE 0x01 

idefine MPTN~NATIVE 0x02 

idefine fcrafSOJIND 0x04 

idefine MPTN'SO UNBIND 0x08 

idefine MPTN~S0~C0NN 0x10 

idefine OTNJ0J0M0RB.C0NN 0x20 

ftdefine MPTN SO.LISTEN 0x40 
idefine MPTNJ0_C0NJEAD_HAIT 0x80 

idefine MPTN_S0_C0N HEAD RCVD 0x0)00 
ftdefine MPTN S0_C0N HEAD SENT 0x0200 
idefine MPTNIsO.CON'ESTABLISHED 0x0400 
idefine MPTN S0JL0SE0 0x0800 
idefine MPTNJO.BCAST.RCY 0x1000 

idefine MPTN SO IN ADDR ANY 0x2000 



/* indicates nonnative connection */ 
/* indicates native connection */ 
/* sock nptn state->addr bound */ 
/* sock nptn state*>addt not bound*/ 
/* sock nptn state*>connect reg is nade*/ 
/* ->there will be no more conn, re-try 

* over other networks/ protocols*/ 
/* init state of a passive sock */ 

/* native con set up.. waiting for MPTN 

* connect header */ 

/* passive node.. .mptn con revd..*/ 
/* Active node.. .nptn con sent ..*/ 
/* Connection established . ..*/ 
/* local socket close issued */ 
/* the socket is enabled to rev 

* broadcast dgns.*/ 

/* the socket is bound to in_addr_any */ 



7 



EP 0 613 274 A2 



5 



* Socket state bits. 
*/ 

Mefine SS HQFDREF 
ttefine SS~ISCOtMBCTGD 
idefine SSJSCGNNBCTIMG 
Wefine SS ISDISCONNBCTING 
Wef ine SS CtoJISSNDMORE 
ffdefine SS CAKTRCVNORE 
ltdefine SS_RCVAIHARK 



OkOOJ 
0x002 
0x004 
0x003 
0*010 
0x020 
0x040 



/* no file table ref any aore V 
/* socket connected to a peer */ 
/* in process of connecting to peer */ 
/* in process of disconnecting */ 
/* can't send more data to peer */ 
/* can't receive aore data from peer */ 
/* at nark on input */ 



10 



Wefine SS PR IV 
ftdefine SS HBIO 
Wef ine SS ASM! 



0x080 
0x100 
0x200 



/* privileged for broadcast, raw... V 
/* non-blocking ops V 
/* async i/o notify V 



define SS CANCEL 
ttdef ine SSJUSHSSEN 



0x4000 
0x8000 



/* cancel call */ 
/* seen push */ 



15 L* Rest of the info is the same as in the BSD4.3 socketva.h V 
Copyright. IBM Corp. 1993 

Conventional socket creation starts with a call to the socket API. A domain table is searched for the address 
family, the type and protocol which is desired by the application. If a match is found the protocol switch table 

20 entry is set in the socket control block. Next, the user requests entry and the selected protocol is called to 
create of the protocol control block. If a match is not found in the domain table for the address family, type and 
protocol desired by the application, an error is returned to the application. 

FIG. 5 depicts the process of creating a socket according to the present invention. The process begins 
with a socket creation request 150 from an application to the socket API, the application wishes to send or 

25 receive data across the network. The command to the socket API for the request takes the form of socket=(AF, 
*, type, proto). "AF" refers to the address family and communication domain; "type" refers to one of the socket 
types defined in a system header file. The "proto" or protocol parameter is used to indicate that a specific pro- 
tocol is to be used. A test is performed in step 1 52 to determine if "proto" is specif ied. If so, the normal socket 
creation process in step 154 is carried out and the process ends, step 155. 

30 If "proto" is not specified, the process continues to create a multiprotocol socket. Each protocol is associ- 
ated with a protocol switch table. For each protocol switch table, step 155, tests are performed whether the 
type and address family of the requesting endpoint, steps 158 and 160, are matched by the protocol. In step 
158 the test for "type" match is performed. If the test fails, the process returns for the next protocol switch 
table, step 1 56. If the test succeeds, the test for address family match is performed in step 1 60. Both the "type" 

35 and "family" are represented as integers. By matching, the socket layer compares the 'type* and "address fam- 
ily' field supplied by the user and the 'type* and "address family" fields in the protocol. If a match is found for 
both type and address family, the protocol is selected as a candidate protocol and set in the socket extension 
with pointers to the protocol switch table and protocol control block, step 162. If there is no match, the process 
determines whether the address family is supported non-natively in the network, step 164. If the protocol is 

40 supported, step 1 66, the protocol is selected as a candidate protocol and set in the socket extension with poin- 
ters to the protocol switch table and protocol control block, step 162. If the protocol is not supported, in step 
166, a test is performed to determine whether it is the last protocol switch table. If not, the process returns to 
step 1 56. If it is the last protocol switch table, the process ends, step 1 70. The protocol pointers can be reordered 
within the extension according to the application or user preference through the use of a configuration tool or 

45 according to information from the named server. 

In FIG. 6, the process to establish a connection using the multiprotocol socket is described. The process 
begins in step 200 where the socket layer tries connecting to a specified destination using the first protocol 
from the list of protocols in the socket extension. The choice of which of the protocols to try first can be based 
on the configuration of user specified preference order of protocols. If the connection succeeds, step 222, the 

so process ends in step 223. If not, the next protocol is used to try to establish a connection in step 224. Tests 
are performed determine whether a connection is made, step 226. If so, the process ends, if a connection is 
not made, a test is performed to determine whether it is the last protocol in the socket extension. If not, the 
next protocol in the extension is tested, step 224. If all the protocols used when creating the socket have failed 
to provide the connection, the transport provider returns a notification of failure to the application, step 232. 

55 As mentioned previously, the invention finds use in a plurality of computers which are part of a network 

such as a Local Area Network or wide Area Network. Although the specific choice of computer in these net- 
works is limited only by performance and storage requirements, computers in the IBM PS/2 (TM) senes of com- 
puters could be used in the present invention. For additional information on IBM's PS/2 series of computers, 
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the reader is referred to Technical Reference Manual Personal Systems/2 Model 50, 60 Systems IBM Corpor- 
ation, Part No. 68X2224 Order Number 568X-2224 and Technical Reference Manual Personal Systems/2 
(Model 80) IBM Corporation Part No. 68X 2256 Order Number S68X-2254. One operating system which an 
IBM PS/2 personal computer may run is IBM's OS/2 2.0 (TM). For more information on the IBM OS/2 2.0 Op- 

5 erating System, the reader is referred to OS/2 2.0 Technical Library. Programming guide Vol. 1. 2. 3 Version 
2.00 Order Nos. 10G6261 , 10G6495, 10G6494. In the alternative, the computer system might be in the IBM 
RISC System/6000 (TM) line of computers which run on the AIX (TM) operating system. The various models 
of the RISC System/6000 are described in many publications of the IBM Corporation, for example, RISC Sys- 
tem/6000. 7073 and 7016 POWERstation and POWERserver Hardware Technical reference, Order No. SA23- 

10 2644-00. The AIX operating system is described in General Concepts and Procedure--AIX Version 3 for RISC 
System/6000 Order No. SC23-2202-00 as well as other publications of the IBM Corporation. In lieu of the cited 
references, the reader is offered the following general description of a computer system which could be utilized 
to practice the present invention. 

In FIG. 7, a computer 310, comprising a system unit 311, a keyboard 312, a mouse 313 and a display 314 

15 are depicted. The screen 316 of display device 314 is used to present the visual changes to the data object. 
The graphical user interface supported by the operating system allows the user to use a point and shoot method 
of input by moving the pointer 315 to an icon representing a data object at a particular location on the screen 
316 and press one of the mouse buttons to perform a user command or selection. 

FIG. 8 shows a block diagram of the components of the computer shown in FIG. 7. The system unit 11 

20 includes a system bus or plurality of system buses 21 to which various components are coupled and by which 
communication between the various components is accomplished. The microprocessor 322 is connected to 
the system bus 321 and is supported by read only memory (ROM) 323 and random access memory (RAM) 
324 also connected to system bus 321. A microprocessor in the IBM multimedia PS/2 series of computers is 
one of the Intel family of microprocessors including the 386 or 486 microprocessors. However, other micropro- 

25 cessors included, but not limited to, Motorola's family of microprocessors such as the 68000, 68020 or the 
68030 microprocessors and various Reduced Instruction Set Computer (RISC) microprocessors manufactured 
by IBM, Hewlett Packard, Sun, Intel, Motorola and others may be used in the specif ic computer. 

The ROM 323 contains among other code the Basic Input-Output system (BIOS) which controls basic hard- 
ware operations such as the interaction and the disk drives and the keyboard. The RAM 324 is the main memory 

30 into which the operating system, transport providers and application programs are loaded. The memory man- 
agement chip 325 is connected to the system bus 321 and controls direct memory access operations including, 
passing data between the RAM 324 and hard disk drive 326 and floppy disk drive 327. The CD ROM 332 is 
also coupled to the system bus 321. 

Also connected to the system bus 321 are various I/O controllers: The keyboard controller 328, the mouse 

35 controller 329, the video controller 330, and the audio controller 331 which control their respective hardware, 
the keyboard 312, the mouse 313, the display 314 and the speaker 315. Also coupled to the system bus 321 
is the digital signal processor 333 which corrects the sound produced by the speaker 315 and is preferably 
incorporated into the audio controller 331. An I/O controller 340 such as a Token Ring Adapter enables com- 
munication over a network 342 to other similarly configured data processing systems. 

40 While the invention has been described with respect to particular embodiments above, it will be understood 
by those skilled in the art that modifications may be made without departing from the spirit and scope of the 
present invention. The preceding description has described the principles of the present invention in terms of 
a particular communications endpoint object, a socket, in the socket layer between the application layer and 
transport layer. The principles of the invention could be extended to provide similarly configured communica- 

45 tion endpoint objects in other layers. For example, an object in the network interface layer could be used to 
monitor a plurality of underlaying MAC drivers to that data could be sent or received over a plurality of MAC 
protocols to different types of networks. These embodiments are for purposes of example and illustration only 
and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims. 

50 

Claims 

1. A method for communicating between nodes in a computer network in which a plurality of protocols are 
useable by network nodes, the method comprising the steps of: 
55 creating communication endpoint objects defining communication parameters for respective net- 

work nodes, the objects having information about the plurality of protocols which are useable by said node 
for inter-node communication; and 

at the time communication is requested between said nodes, establishing a connection between 
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said nodes using a selected one of the plurality of protocols. 

A method according to claim 1, wherein the selected protocol is chosen based on user preferences. 

A method according to claim 1 ? wherein the selected protocol is chosen based on a capability of the se- 
lected protocol. 

A method according to any one of the preceding claims, wherein the creating step comprises the steps 
of: 

requesting information of each of the plurality of protocols; 

selecting a set of protocols from the plurality of protocols, which selected protocols are useable by 
the respective nodes; 

building a protocol control block for each of the selected protocols; and, 
inserting a pointer in the communication endpoint object for each protocol control block of a se- 
lected protocol. 

A method according to claim 4, wherein the order in which the pointers are inserted is based on user pref- 
erence. 

A method according to claim 4 wherein the selecting step comprises the steps of: 

determining whether there is a match for a first protocol for a first set of protocol parameters, the 
first protocol corresponding to a first pointer in the socket; and, 

responsive to finding no match for the first protocol, determining whether the first protocol is sup- 
ported non-natively in the network. 

A system for communicating between nodes in a computer network in which a plurality of protocols are 
useable by network nodes, the system comprising: 

means for creating communication endpoint objects defining communication parameters for re- 
spective network nodes, which objects have information about the plurality of protocols useable by re- 
spective computer systems each coupled to one or more nodes in the network; and, 

means for establishing a connection between a first and a second computer system using a se- 
lected one of the plurality of protocols at the time communication is requested between nodes on the dif- 
ferent systems. 

A system according to claim 7, which further comprises: 

means for selecting a set of protocols from said plurality of protocols; 

means for requesting information from each of the plurality of protocols; 

means for building a protocol control block for each of the selected protocols; and, 

means for inserting a pointer in the communication endpoint object for each protocol control block 
for a selected protocol. 

A system according to claim 8, which further comprises: 

means for determining whether there is a match for a first protocol for a first set of protocol para- 
meters, the first protocol corresponding to a first pointer in the socket; and, 

means for determining, responsive to finding no match for the first protocol, whether the first pro- 
tocol is supported non-hatively in the network. 
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